A computing device, such as a server, router, desktop computer, laptop, etc., includes an operating system layer and an application layer to enable the device to perform various functions or roles. The operating system layer includes a “kernel” (i.e., master control program) that runs the computing device. The kernel provides task management, device management, and data management, among others. The kernel sets the standards for application programs that run on the computing device and controls resources used by application programs. The application layer includes programs, i.e., executable instructions, which are located above the operating system layer and accessible by a user. As used herein, “user space”, “user-mode”, or “application space” implies a layer of code which is less privileged and more directly accessible by users than the layer of code which is in the operating system layer or “kernel” space. The operating system layer has software programs that include a set of Application Program Interfaces (APIs). The language and/or message format of the APIs allow an operating system to interpret executable instructions received from program applications (e.g., service applications) in the application layer and return results to the programs in the application layer.
When the execution of the program instructions call for data or other program instructions, the program will want to know where in memory the data or instructions are stored. In effect, the program will use a means for referencing or indexing where in memory the data or instructions are held. The kernel is responsible for memory management. A process is assigned its own memory address space, e.g., virtual memory address space, which may not be available to other processes. When a process uses a virtual memory address the virtual memory system translates it into a physical address using a virtual to physical address mapping contained in some type of look up structure and address mapping database. Addresses exist for both software components and hardware. Physical addresses are partitioned into input/output (I/O) space and memory space. The I/O space is associated with peripheral hardware devices.
More and more operating systems (OSs) are interfacing with advanced configuration and power interface (ACPI) systems. ACPI provides power management, configuration, and other extended capabilities. ACPI is an open industry interface specification that provides a way of communicating system information from firmware to the OS and a means of providing runtime firmware control methods, as well as a set of fixed hardware for the OS to access.
Many operating systems support hibernate semantics, i.e., sleep states, in which I/O is quiesced, system, processor, and memory state are saved to disk, and the system is shut down to save power. In programming parlance a “state” refers to the current or last-known status, or condition, of a process, transaction or setting. A persistent state preserves or maintains state information regardless of surrounding operations or environmental computing device conditions which are occurring, e.g., keeping track of the process despite power failures or loss of state in RAM or processors.
ACPI systems include a set of hibernation semantics. For example, in ACPI version 2.0, incorporated herein by reference, hibernate semantics are defined in association with an S1-S5 state, (S1-S4 are sleeping states, and S5 is a soft off state). Each of these states preserves some form of system context, i.e., the current status, condition, or mode of a system. Hence, each of these states preserves some form of state associated with the status or condition of a process, transaction, or setting. According to ACPI 2.0, S4 (“hibernation state”) is the lowest-power, longest wake-latency sleeping state and can save and restore all system context. That is, upon power on, the S4 state is used to restore the system to its previous state, and resume the execution of programs where they left off before entering the sleep state.
To date, migration of a workload, e.g., operating system image, to other machines often involves shutting down the machine first and then migrating the workload when a system specific state associated with the program applications on the machine. Alternatively, machines can be clustered to commonly access system specific state information, e.g., to access shared data and operate as computer nodes. In some scenarios, stateless applications are provided such that alternate computer nodes, e.g., servers or other devices having processor logic and memory resources, can pick up where another computer node left off. In a bladed server environment workloads are often stateless and either have copies of static data, or access shared data. However, other applications, e.g., that are stateful, can not approach this problem in the same manner, and/or clustering the applications in a bladed environment may not make sense for one particular architectural reason or another. Hence, each of the above approaches to migrating a workload can involve significant downtime, added cost in creating a clustered environment, and/or time and resource expense to change existing software to be more stateless.